|
Message Constraints for the ED datatype
| |||
Programme | NPFIT | DOCUMENT RECORD ID KEY | ||
Sub-Prog / Project | Comms & Messaging | NPfIT-FNT-TO-DPM-0314.01 | ||
Prog. Director | Tim Jones | |||
Owner | Margaret Baldock | Version | 1.0 | |
Author | Core Technical Team | |||
Version Date | 7/1/2005 | Status | Issued | |
Message Constraints for the ED datatype
Amendment History:
Version | Date | Amendment History |
0.1 | First draft for comment | |
1.0 | Issued Version | |
Forecast Changes:
Anticipated Change | When |
Document Status:
This is a controlled document.
This document version is only valid at the time it is retrieved from controlled filestore, after which a new approved version will replace it.
On receipt of a new issue, please destroy all previous issues (unless a specified earlier issue is baselined for use throughout the programme).
Contents
2.2. Support for Non Browser Interfaces
2.3. Requirement for well-formed XHTML
2.4. Use of Namespace attribute.
2.5. Permitted tags and attributes
1. Purpose
This document specifies how to use the ED data type to convey textual information within HL7 messages. This document does not apply to the use of ED data type for use with Presentation Text. This is documented here
Many media types can be catered for within an ED data types but only two are considered here.
- Text/plain is a required media type which is always supported.
- Text/html which is used where formatting is a business requirement.
Text/html in an unconstrained form would cause problems so below is a table containing a restricted set of XHTML tags that may be used where simple formatting is a business requirement.
Theses restrictions are specifically designed to prevent :-
- Inclusion of external hyperlinks that invoke or reference material not within the message.
- This is considered necessary to ensure all material relevant is communicated and to avoid risks from linking to material that is not constrained by the message specification and may thus include viruses or other rogue software.
- Inclusion of complex formatting which may not be supported by a receiving system
- Representation of structured computer parsable semantics in a document that is intended only for presentation to a human reader.
2. Specification
2.1.
Mapping to HL7 CDA
There is a mapping provided in the table below which indicates how this constrained xHTML maps to the HL7 CDA body structures. The structures defined here are more constrained than CDA, but will map to a true subset of that document definition.
2.2. Support for Non Browser Interfaces
It is assumed that some applications will want to display the received text within an existing user interface, rather than directly in a browser. Were the narrative text always going to be viewed with a browser (or browser component), then we need only constrain to the point of a reasonable baseline browser conformance. However if this data may be displayed within non-browser user interfaces, then style and layout markup should be kept to a minimum.
This specification defines a minimum set of markup that all receivers must be able to process, and allows further markup that the receiver can ignore if they wish to display the data within an existing user interface template.
2.3.
Requirement for well-formed XHTML
If formatted text is a requirement then XHTML rather than HTML shall always be used.
The main implications of this are:
- The document must be well-formed according to XML rules.
- All opening tags must either be balanced by closing tags or must be marked empty
- The following is correct ...
- <body><h1>A heading</h1><p>A paragraph broken here<br/>and
ended here</p><p>Another paragraph</p></body> - The following would produce the same results in most HTML browsers but is not well-formed according to the rules of XHTML and thus generates an XML parser error ...
- <body><h1>A heading</h1>A paragraph broken here<br>and
ended here<p>Another paragraph</body> - All attribute values must be enclosed in quotations
- For example the following is correct ...
- <table border="1">
- But the line below generates a parser error ...
- <table border=1>
2.4.
Use of Namespace attribute.
Within the <html> tag you should declare a namespace using the xmlns attribute as follows:
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/1999/xhtml ..\dt\xhtmlNPfIT.xsd">
2.5.
Permitted tags and attributes
Tag | Description | Permitted attributes | Mapping to HL7 CDA |
<html> | Top level element containing an instance of <head> and an instance of <body>. | xlmns, xsi:schemaLocation | |
<head> | One instance only in the <html> element. Restriction: This may only contain two sub-elements <title> and <style>. | | |
<style> | One instance only in the <head> element. This element may be ignored by receiving systems that do not use a browser component to display the narrative text. It is the sender’s responsibility to ensure that this does not alter the semantic meaning. | | |
<title> | One instance only in <head> element. This provides a document title. | | caption |
<body> | One instance only in the <html> element following the <head> and containing the remainder of the document. | | |
<h1> | Heading levels. Restriction: These are not permitted to contain any sub-elements. | | |
<p> | Paragraph | | paragraph |
<ol> | Outline list numbered and unnumbered. | | list |
<li> | List item | | item |
<table> | Table | width, cellpadding, cellspacing, border | table |
<thead> | Table header | valign | thead |
<tfoot> | Table footer | valign | tfoot |
<tr> | Table row | valign | tr |
<td> | Table cell | rowspan, colspan, nowrap, width, height | td |
<pre> | Preformatted text -- this has been included to represent fixed width fonts where layout is controlled by whitespace, as for the pathology result messages. Restriction: The sending system should convert any tabs to spaces when sending a message to avoid misaligned text. | | |
<a> | Internal links Restriction: The href URL for an internal link must start with #, indicating that it is a pointer into the current document. | name, href="#...." | link_html |
2.6.
Common Attributes
Class and style are permitted attributes but maybe ignored by receiving applications. It is the sender’s responsibility to ensure information is represented safely and appropriately whether or not these additional attributes are processed.
2.7.
Schema
Click here to see a schema that will validate restricted Xhtml fragments used within messages.
3.
Reserved Characters
Certain ASCII characters should not be used within XML/XHTML or even plain text fragments as they have a special meaning. Whereas this applies to all data types problems are most likely to arise within Encapsulated Data or Strings. Therefore the following characters must only be used via the appropriate entity name.
|
e.g. The following will cause syntactical errors in a message due to the presence of a ampersand character:
<value>Patient was sent to A & E</value>
It should be expressed as:
<value>Patient was sent to A & E</value>
More information can be found at http://www.w3.org/TR/xhtml1